Voice over Internet Protocol (“VoIP”) networks are gaining widespread use in telecommunications. Effective operation of VoIP networks requires managing the devices that provide VoIP services. VoIP may be implemented at Layer 3 of the Open Systems Interconnect (OSI) logical network model, and therefore VoIP data packets are routable and can be carried transparently over any type of packet network infrastructure. Routers are network layer devices that are used to determine the optimal path along which network traffic, such as VoIP, can be forwarded. Routers can forward packets carrying call related data from one network to another network based on network layer information.
A challenge relating to managing devices, such as routers and the resources or entities in routers, is how to represent the wide variety of router platforms in data that can be processed by a network management software application. For example, one router platform may have 5 ports to each slot, whereas another router platform may have shelves, each shelf may have 3 slots, and each slot may have one or more sub-slots. There may be other elements that require data representation as well. For example, as data for a telephone call travels along a network infrastructure, the call related data encounters managed devices, such as routers, in the network. The call related data flows through a Digital Signal Processing (DSP) Channel on a DSP chip in the router. A particular router may have shelves, the shelves may have slots, the slots may have sub-slots, the sub-slots may have DSP chips and the DSP chips may have DSP channels. To track the call related data, ultimately routers need to store information that relates this call to the entities, e.g., shelves, slots, etc., used in the call. The problem is how to describe and represent all of these platforms in data for the purpose of device management.
Similar problems exist with respect to any association of a call and its resources (trunk, line, DSP channels and others). The calls can be modem, voice, fax or clear channel data/voice calls and are not only VoIP calls.
In devices that are managed using Simple Network Management Protocol (SNMP), one way of representing devices is with Managed Information Bases, or MIBs, which are databases hosted by the devices that contain MIB objects that represent the various characteristics and attributes of a device. For example, “chassis MIBs” often represent constituent entities of a chassis such as shelves, slots, ports, etc.
Many chassis MIBs are designed with a particular platform in mind and hence are platform dependent. A MIB that is designed for a particular platform cannot, in general, be used to manage another platform, particularly if the other platform has a different configuration of physical entities. For example, a chassis MIB designed for a router platform (hereinafter referred to as a “router MIB”), which contains slots and ports, may use two separate MIB objects—MIB slot object and MIB port object—to represent the third port in the fifth slot: In this case, the MIB port object has the value of 3 to represent the 3rd port and the MIB slot object has a value of 5 to represent the 5th slot. The drawback of such a design is that the same MIB cannot represent the location of physical entities on different platforms. For example, the router MIB described herein cannot be used to represent a platform with slots and sub-slots or be used to represent the locations of physical entities in a multi-chassis system. Multi-chassis systems, such as high-end router platforms, are composed of multiple chassis or “racks”, each of which contain multiple slots. MIBs that represent entities of particular platforms shall hereinafter be referred to as “platform dependent MIBs”.
The Entity MIB is an IETF standard (RFC 2737) that provides a platform independent way of representing physical entities in devices. The entPhysicalTable of the Entity MIB represents physical entities in the device chassis, and also indicates the containment relationship of the physical entities to the parent entity. For example, a port may be identified by an index value of 101 in the entphysical Table. Furthermore, the value of the associated MIB object entPhysicalContainedIn may indicate that the port is contained in the entry identified by value 100, which represents a slot in the chassis. Thus the various entries in the entPhysicalTable of the Entity MIB describe a hierarchical containment tree, which indicates the relationship between various physical entities in the device chassis.
However, in this approach, a network management software application is required to traverse a tree of objects in the Entity MIB to determine that 101 is the first port in slot 100. Thus, Entity MIBs are complicated and difficult to understand, and the tree traversal requirement can impose a performance impact on an application that is interacting with the Entity MIBs. Typically many queries are required to traverse the containment tree of an Entity MIB, resulting in performance degradation. Furthermore, the Entity MIB is not adequate to describe the location of a logical entity, i.e., not a physical entity, such as a DSP channel or a logical network interface.
Based on the forgoing, there is a clear need for a mechanism to indicate, in a platform independent manner, the location of both physical and logical managed entities within a managed device. Furthermore, there is a need to manage both physical and logical entities.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.